[レポート] サーバーレスアプリケーションの最適化 SVS401-R #reinvent

AWS re:Invent 2019 SVS401-R - [REPEAT] Optimizing your serverless applicationsのセッションレポートです。

AWS re:Invent 2019

#AWS Lambda

#AWS

Satoshi Noto

2019.12.24

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWS re:Invent 2019 SVS401-R - [REPEAT] Optimizing your serverless applicationsのセッションレポートです。昨年も同様のセッションが存在し、そのアップデートのため最初から名前に[REPEAT]がついているようでした。昨年のセッションレポートは以下になります。

[レポート] SRV401 : サーバーレスアプリケーションの最適化 #reinvent

セッション情報

登壇者

CHRISTOPHER MUNNS - Principal Developer Advocate, Amazon Web Services

概要

Are you an experienced serverless developer? Do you want a handy guide for unleashing the full power of serverless architectures for your production workloads? Are you wondering whether to choose a stream or an API as your event source, or whether to have one function or many? In this session, we discuss architectural best practices, optimizations, and handy cheat codes that you can use to build secure, high-scale, high-performance serverless applications. We use real customer scenarios to illustrate the benefits.

動画

スライド

https://d1.awsstatic.com/events/reinvent/2019/REPEAT_1_Optimizing_your_serverless_applications_SVS401-R1.pdf

レポート

ボリュームが多いため、まとめと新機能を中心としたレポートにしています。

まとめ

実際にはセッションの最後に紹介されたスライドですが、よくまとまっているので最初に載せておきます。気になる部分は実際にセッション動画もしくはスライドを参照してください。

自作するLambda関数要約
- 依存関係は最小化する
- プリハンドラーロジックは控え、使用するなら戦略的に用いる
- アプリケーションのスコープに応じてシークレットを共有する
  - 単一の関数 : 環境変数
  - 複数の関数 : SSMパラメーターストア
- 影響のある変数、コネクション、依存関係をどうやって再利用するか検討する
- Lambdaレイヤーはコードの重複を防ぎ、関数へのアクセス方法を標準化できる
- Amaozon RDS ProxyはRDBMSの使い方を簡単にする
- 簡潔なロジック
- オーケストレーションコードはStep Functionsに出す
- Lambda Event Destinationsは非同期処理のワークフローを単純化する
実行環境要約
- よりメモリが必要ということはよりCPUとI/Oが必要なことを意味する（比例的に）
  - コストを下げることもできるかもしれない
- ワークロードをプロファイルするためX-Rayを使用する
- 使用しないかも知れないし、必要かも知れないが、1.8GBのメモリでCPUのコアは2になる（1.8GBより少ない場合のコア数は1になる）。
- 実行元がどのような実行モデルを必要とするのかよく考える
  - 全てをAPI（同期モデル）とする必要はない
- 非同期に考えることでスケーリングの問題を克服できるだろう
- キュー、トピック、ストリーム、イベントバスを利用する際は様々な観点を理解して使用する
- IAMのスコープは最小化する
  - AWS SAMのようなツールを使用する
Lambdaサービス要約
- Provisioned Concurrencyは関数の一貫性と全体的なレイテンシーを改善するだろう

Amazon RDS Proxy

新機能
LambdaからRDSへの接続をシンプルにする
Lambdaの場合はデータベースへのコネクション数が多くなるという問題があったが、データベースに対する共有コネクションプールを提供することでコネクション数を減らす
簡単に認証ができるようSercrets Managerに統合されている
透過的に利用できるようにデータベースのフェイルオーバーを対処する
現時点でプレビュー、限られたリージョン、MySQLのみ
[NEW]「Lambda-RDS」パターンももう怖くない！？フェイルオーバーももっと早くなるよ！ RDS Proxyがプレビュー公開されました！#reinvent ｜ Developers.IO
[速報]これでLambdaのコネプー問題も解決？！LambdaからRDS Proxyを利用できるようになりました(まだプレビュー) #reinvent ｜ Developers.IO

Lambda Event Destinations

新機能
非同期実行において成功と失敗をキャプチャできる
レコードはJSONフォーマットのリクエストとレスポンスに関する詳細な情報を含む
DLQに送信するよりもより情報を含む
成功と失敗の両方を同じ宛先に送信することもできるし、それぞれ別の宛先に送信することもできる
AWS Lambda が非同期呼び出しの宛先指定をサポート
Introducing AWS Lambda Destinations | AWS Compute Blog

Lambda + VPCにおけるコールドスタート問題がなくなった

新機能
全リージョンで利用できる
【速報】もうアンチパターンとは呼ばせない！！VPC Lambdaのコールドスタート改善が正式アナウンスされました！！｜ Developers.IO

最近の非同期イベントソース関連のアナウンス

EventBridge

Provisioned Concurrency for Lambda

新機能
初期化フェーズまで経過した実行環境を事前に生成しておける
レイテンシーが問題になる環境向け
通常のLambdaの場合は95パーセンタイルからレイテンシーが大きくなるが、Provisioned Concurrency for Lambdaの場合はレイテンシーが一貫している
現在利用しているLambdaのコードをそのまま、もしくはほんの少し変更すれば利用できる
AWS Auto Scalingで制御できる
事前に実行環境を用意するコストはかかるが、リクエスト自体のコストはさがる。そのため、大量のリクエストを処理する場合はコストを削減できる
[速報]コールドスタート対策のLambda定期実行とサヨナラ！！ LambdaにProvisioned Concurrencyの設定が追加されました　 #reinvent ｜ Developers.IO
LambdaのProvisioned Concurrencyを使って、コールドスタート対策をしてみた #reinvent ｜ Developers.IO
安い？それとも高い？Provisioned Concurrencyを有効化したLambdaのコストに関する考察 #reinvent ｜ Developers.IO

感想

途中で去年受講したセッションだと気づき、あまり得ることはないかと思ったのですが、この1年のLambda関連のアップデートを確認できてよかったです。特にre:Invent直前の大量アップデートは押さえられていなかったので、このセッションレポートを書きながら関連情報を読み込んで理解できました。Lambdaの最適化についてまとまったよいセッションだと思いますので、Lambdaを利用されている方はスライドだけでも参照することをおすすめします。